ai-gov: http method and path rules, and approval-required network access - #26051

read through the diff and cross-checked against the actual implementations in governor-lib, governor-services, sandboxes, and the two open frontends PRs (#17054 and #17125). overall the HTTP method/path docs are solid; the approval section has one critical bug to resolve before it can be accurate.

critical: PR #17054 currently breaks the approval feature entirely

the sandboxd network approval handler (user_prompts_network.go) explicitly bails out when the policy's maxScope is not ScopePersistent:

if !approvalScopeOffered(pending.Options, approval.ScopePersistent) {
    // returns false, no prompt is published
    return false
}

PR #17054 as currently written hardcodes maxScope: 'APPROVAL_SCOPE_PER_REQUEST' in the create/edit action. with that value, approvalScopeOffered(options, ScopePersistent) is false on every request, the handler exits without publishing a prompt, and approvalPromptPublished stays false. the user message then falls through to the generic denial branch, the "Approval required for X. Review and respond with: sbx policy approval ls" message never appears, no entry shows in sbx policy approval ls, and there is nothing the developer can respond to. every gated destination is silently blocked.

the fix is maxScope: 'APPROVAL_SCOPE_PERSISTENT'. the docs describe the persistent flow throughout (stored rules, sbx policy ls --created-via approval, sbx policy rm network to remove them, sbx policy reset clears them), all of that only works when the scope is Persistent, which is what the sandboxes daemon actually requires.

HTTP rules: accurate (a few notes)

• method list: backend httpMethodNames in spec.go has all 9 (GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, CONNECT, TRACE), docs are correct that local CLI accepts all 9. the org UI (PR #17125) exposes only 7 (no CONNECT, TRACE). the org.md caveat "from the methods listed" and the concepts.md note "the methods you can select individually depend on where you configure the rule" cover this correctly.

• "any ()" in the org composer: the current NetworkRuleComposer sends an empty actions array → http:request:* wildcard (all 9 methods). the new card-based form in PR #17125 converts empty actions to [...L7_REQUEST_ACTIONS] = the 7 specific actions instead of the wildcard. the docs say "every method the composer offers" which is the accurate qualifier either way, but worth flagging: after #17125 lands, "any ()" in the org UI explicitly covers only the 7 shown methods. a sandbox making a CONNECT or TRACE request to that destination would not match the org allow rule.

• composerFormToPendingRule in PR #17125: empty patterns array → appends /** to the destination. the docs claim "leave it empty to match any path" is correct.

• the concepts.md layering table, the "HTTP allow only" row, and the "network deny is a floor" framing all match the engine behavior i could verify.

approval flow mechanics: accurate

• "approval required" message format matches engine_governance.go: "Approval required for " + host + ".\n\nReview and respond with:\n sbx policy approval ls" with the support message appended after a blank line ✓
• deduplication ("repeated attempts collapse into a single entry") is handled by userPromptManager.Request using a deterministic ID keyed on sandbox+action+resourceType+host ✓
• sandbox-scoped grants: the resolve call uses WithRequestAttribute(ConditionTypeSandboxID), "another sandbox reaching the same destination asks again" ✓
• "preset rules and local adds don't satisfy approval", the resolver only checks MechanismApproval provenance ✓
• "a local deny takes precedence over an approval requirement" ✓
• "dismiss" leaves no persistent rule, destination is requested again next time ✓
• "reset clears approvals", approvals live in the local policy store, reset wipes it ✓

depends on unmerged work

• all of the org UI HTTP rule section (Type dropdown, HTTP methods chips, Path patterns, All traffic) depends on PR #17125, which is open
• all of the "Require approval before access" org UI section (toggle label, placement, detail page "Required"/"Not required") depends on PR #17054, which is open and currently has the maxScope bug above